Skip to main content

Request Elements in PostQode

To pass the data into an API Request in PostQode, refer to the sections below:

Parameters​

Request parameters are used to send additional information to the server. While these parameters are typically included in the URL, PostQode will offer a separate action to conveniently add and manage them.

Authorization​

APIs use authorization to ensure that the request is sent by an authorized user.

PostQode supports four types of authorization that are given below:

No Auth - This is suitable for the APIs which are public or when the authorization is not required.

Bearer Token - This allows a request to authenticate using an access key, such as a JSON Web Token.

Basic Auth - This is used by an HTTP user agent (e.g., a web browser) to provide a username and password while making a request.

Digest Auth - Similar to the Basic Auth, but does not require any password to be transmitted.

Request headers provide a crucial context to the server about the request that is being created. In PostQode, you can customize the headers to include any specific information relevant to your API interaction. The commonly used Headers are given below:

  • Content-Type: Specifies the format of the data in the request body (e.g., application/json, application/xml).
  • Accept: Specifies the expected data format for the response from the server.
  • Authorization: Includes the authentication credentials for the requests to be secured (For example, Bearer token, Basic authentication).

Preset Headers​

Preset headers in HTTP requests refers to the commonly used headers that provide essential information about the request or the client to the server. These headers are standardized and serve for the various purposes, including the authentication, content negotiation, and caching. The commonly used Preset Headers are given below:

  • Authorization: Provides credentials for the authentication, such as a Bearer token or Basic authentication credentials.

  • Content-Type: Specifies the format of the request body data, such as application/json, application/xml, or multipart/form-data.

  • Accept: Indicates the expected format of the response from the server which helps to negotiate the content.

  • User-Agent: Identifies the client who creates the request, typically including the information about the software (browser or API client) and its version.

  • Cache-Control: Directives for caching mechanisms in both requests and responses to control caching behavior.

  • Cookie: Includes cookies associated with the request, allowing for session management and stateful interactions.

  • If-Modified-Since: Allows conditional requests based on the last-modified timestamp of a resource, reducing bandwidth usage.

These headers are integral to how HTTP works and are managed by both clients (such as browsers or API clients) and servers to ensure effective communication and functionality. When using tools like PostQode or making HTTP requests programmatically, to understand and utilize these headers correctly can make a significant impact on the reliability and security of your interactions with the web services.

Body​

While sending an API request, the data can be added either in the request Body or in the Parameters depending on the request method. If the request method demands request body, then you can add the data to the body of an API request.

PostQode supports five types of request bodies as given below:

None - This type of request does not contain a body.

Raw - This type of body is used to send the data in bulk or as a string and it also supports various types of raw data. The request body accepts the data in the formats as given below:

  • JSON
  • HTML
  • XML
  • JavaScript
  • Text

Binary - This type of body is used to send the files, videos, images or audio files along with the request.

Form Data - This type of body is used to send the data in the form of key-value pairs. You can add the data by entering it in the fields (Key, Value Type and Value) provided or by linking the value to a dataset.

X-WWW-FORM-URLENCODED - This type of body describes the Form Data that is sent in a single block in the HTTP message body.

Pre-Request​

This section allows you to execute a set of commands before sending the request. These commands can include tasks like setting up variables or generating random values for use in the request. Click the ‘Help’ icon to access the Pre-Request script examples and sample codes. You can also find the Assertion examples when you click on the ‘Help’ icon.

Script​

A script typically refers to a piece of code that you can use to dynamically generate or manipulate the request parameters before sending a request to a server. The script can be written in a scripting language, such as JavaScript.

Settings​

PostQode's Settings feature lets you customize the platform to your preferences. Adjust various parameters to optimize its behavior, functionality, and performance.

A set of more specific settings and their descriptions are given below:

  1. Request Timeout: The maximum duration the platform waits for a response from the server before considering the request that has timed out.
  2. Script Timeout: The maximum duration allowed for the execution of the scripts or the test scenarios.
  3. On Error: Defines the action to be taken when an error occurs during the execution of a test, such as logging the error, retrying the request, or aborting the test.
  4. On Failure: Specifies the action to be taken when a test case fails, such as sending notifications, logging the failure, or executing a customized error-handling logic.
  5. Enabling SSL Certification Verification: Determines whether the platform verifies SSL certificates while making the HTTPS requests.
  6. Automatically follow redirects: Determines whether the platform automatically follows the redirects that are received from the server during a request.
  7. Follow original HTTP method: Indicates the HTTP method (GET, POST, PUT, etc.) for subsequent redirects.
  8. Removing referrer header on redirect: Controls whether the platform removes the referrer header from the request while following the redirect.
  9. Encoding URL automatically: Controls whether the platform automatically encodes URLs in request to comply with the URL encoding standards.
  10. Maximum number of redirects: Sets the maximum number of re-directions allowed for a single request before the platform stops to follow the redirects.
  11. Number of retries: Specifies the how many times the platform should retry a request in case of a failure before considering the request as failed.